篇首语：本文由编程笔记#小编为大家整理，主要介绍了Android编译系统-概览相关的知识，希望对你有一定的参考价值。
http://duanqz.github.io/2015-08-08-build-system-part1-overview#Android%E5%90%AF%E6%99%BA%E8%A7%82
目录
请尊重原创版权&＃xff0c;转载注明出处。
编译&＃xff0c;就是将高级语言转换成机器语言。譬如&＃xff0c;通过gcc将C语言编译成可以运行的二进制;通过javac将Java语言编译成可以在Java虚拟机上可以运行的字节码。
对于简单的项目&＃xff0c;源文件数量较少&＃xff0c;通常只需要几条命令&＃xff0c;组织一下源文件&＃xff0c;调用一下编译器&＃xff0c;生成一个可以运行的文件&＃xff0c;就算是一个“编译系统”; 但对于大型的项目&＃xff0c;文件数量很多&＃xff0c;通常会被组织成众多的模块&＃xff0c;模块之间构成依赖关系&＃xff0c;这就不是简单几条命令就能够成为“编译系统”了。一个大型项目的编译系统&＃xff0c;需要管理好各个模块的依赖关系&＃xff0c;组织好大量的编译中间产物&＃xff0c;具备随时应对模块变更的扩展性&＃xff0c;同时&＃xff0c;也能够高效的完成编译任务。
在Linux上&＃xff0c;一些传统大型项目的编译系统都是基于make这个工具&＃xff0c;make并不是编译器&＃xff0c;仍然需要调用gcc或javac等编译命令来对源码进行编译&＃xff0c;make的输入是一个Makefile文本文件&＃xff0c;make只是按照Makefile文件中定义的规则来完成工作。所以&＃xff0c;这些编译系统中最核心的就是Makefile定义的编译规则和编译顺序&＃xff0c;包括&＃xff1a;哪些源文件需要编译、如何编译、哪些文件存在对其他文件的依赖&＃xff0c;优先编译哪些文件。同其他编程语言一样&＃xff0c;Makefile也有自己的语法&＃xff0c;当正确书写完Makefile文件后&＃xff0c;通过一个make命令&＃xff0c;就能自动完成大型项目的编译。
android编译系统也是基于make的&＃xff0c;要编译出整个Android系统的镜像文件并打包成刷机包(OTA Package)&＃xff0c;编译出SDK和文档(JavaDoc)&＃xff0c;同时&＃xff0c;Android引入了很多第三方开源项目&＃xff0c;需要兼顾不同模块的编译&＃xff0c;仅仅是这些就已经够让Android编译系统受苦了&＃xff0c;还别提支持不同设备厂商的硬件类型&＃xff0c;方便设备厂商进行定制这些兼容性、扩展性、编译效率的问题。Android编译系统的复杂度可见一斑&＃xff0c;纵观整个编译&＃xff0c;除了大量的编译规则文件(Makefile文件片段)&＃xff0c;还有很多Shell和Python脚本组织在一起&＃xff0c;基于make&＃xff0c;但又不同于已有传统项目的编译系统&＃xff0c;Android有自己的一套编译机制。
本文会分析以下问题&＃xff1a;
Android编译系统的设计背景是什么&＃xff1f; 这涉及到Android编译系统设计的意图。
Android编译系统的设计原理是什么&＃xff1f; 这涉及到Android编译系统运转的内在机制。
Makefile文件的书写规则&＃xff0c;不是本文要讨论的内容&＃xff0c;但是Makefile规则的基本形式还是有必要在这里点出来&＃xff0c;作为后续分析的理论基础。
# 规则语法 # 示例
TARGET... : PREREQUISITES... main.o: main.c main.h
COMMAND 1 gcc -c main.c
... ...
COMMAND N echo "Compile finished"
复杂的Makefile规则&＃xff0c;都是由若干基本的规则组合而成。最终&＃xff0c;Makefile会被解析成一个有向无环图(Directed Acyclic Graph, DAG), 每一个目标(Target)构成DAG的节点&＃xff0c;每一个依赖关系(Dependency)构成DAG的边。
同所有基于make的编译系统一样&＃xff0c;Android也需要Makefile文件来定义编译规则和编译顺序。但与大多数编译系统不同的是&＃xff0c;Android并不是Recursive Make的&＃xff0c;那么什么是Resursive Make呢&＃xff1f;
当在Makefile文件中&＃xff0c;使用make命令来编译另一个模块时&＃xff0c;就构成了Resurvise Make。
对于一个大型项目而言&＃xff0c;可以为每个子系统构建一个Makefile文件&＃xff0c;然后在最顶级的Makefile文件中&＃xff0c;调用make命令来编译各个子系统:
subsystem:
cd subdir && make
Resurvise Make的设计能够降低编译的复杂度&＃xff0c;更容易理解和维护&＃xff0c;很多Linux上的大型项目&＃xff0c;包括Linux内核的编译系统&＃xff0c;都是采用的Resurvise Make设计&＃xff0c;但Android并没有采用&＃xff0c;因为这种设计存在很多缺陷。早在1997年&＃xff0c;Peter Miller就在Recursive Make Considered Harmful这篇论文中&＃xff0c;指出了Resurvise Make会导致编译系统“做得太少(do too little)”或“做得太多(do too much)”&＃xff0c; “do too little”会导致最终编译产物可能是错误的结果&＃xff0c;而“do too much”会导致编译效率下降。
TODO&＃xff1a;补充Resurvise Make缺陷的示例
由于Resurvise Make的缺陷&＃xff0c;Android采用了Non-Resursive Make的方式&＃xff0c;将所有的编译规则集中于一个Makefile中&＃xff0c;可以想象最终成型的这个Makefile是极其庞大的。 为了提升编译效率和灵活性&＃xff0c;需要对模块的编译进行控制&＃xff1a;单个模块可以单独进行编译&＃xff0c;不需要的模块不会被重新编译&＃xff0c;以便节省编译时间。
在上述意图的驱使下&＃xff0c;Android编译系统有以下主要的要求 (更详细的要求&＃xff0c;请查阅build/core/build-system.html )&＃xff1a;
编译出多种目标: 除了最终Android系统的产物(譬如&＃xff1a;system.img, boot.img)&＃xff0c;编译系统还要能够编译出很多实用的工具(譬如&＃xff1a;aapt, adb)&＃xff0c;这些工具不仅是编译环境需要的&＃xff0c;也是开发者需要的。
支持多平台&＃xff1a; Android需要在Linux和Mac上进行编译&＃xff0c;编译产出也需要支持Linux和Mac。编译系统对Windows的支持并不好&＃xff0c;但面向开发者的SDK是支持Windows的。
Makefile片段化&＃xff1a;最终的规则集中于一个Makefile&＃xff0c;并不意味着编译系统会维护这么大一个Makefile。为了提高代码的重复利用率&＃xff0c;编译系统包含很多Makefile片段&＃xff0c;最终通过include将片段包含进来。 每一个待编译的模块都会有一个Android.mk&＃xff0c;其内容也是Makefile片段。
自动构建依赖: 模块之间依赖关系是自动构建的&＃xff0c;这意味着&＃xff0c;我们只需要使用编译系统提供的接口&＃xff0c;定义一个模块的编译规则&＃xff0c;不需要关心编译系统如何管理众多模块之间的依赖关系。
至此&＃xff0c;我们分析了Android编译系统重新设计的背景&＃xff0c;主要是为了避免Resursive Make存在的缺陷&＃xff0c;同时应对多模块多平台的高效率编译需求。
在Android源码的根目录有一个Makefile文件&＃xff0c;有效内容只有一行&＃xff1a;
include build/core/main.mk
所有的编译规则都定义在build/core/main.mk文件中&＃xff0c;最终所有的Makefile片段都将汇聚在这一个文件中。
Android编译系统如此强大&＃xff0c;要变成Makefile的最终形态&＃xff0c;当然是要经过很长一段路的&＃xff0c;下图是整个编译系统的框架&＃xff1a;
我们会基于这个图来分析整个Android编译系统的设计原理&＃xff1a;
从Android源码来看&＃xff0c;编译系统的核心功能位于build/core/目录&＃xff0c; 在device和vendor目录下&＃xff0c;存放了与具体机型相关的配置&＃xff0c;这些配置信息都是.mk文件的形式存放的(譬如BoardConfig.mk和AndroidProducts.mk)&＃xff0c; 另外&＃xff0c;每一个模块的编译配置信息都是以独立的Android.mk文件的形式分散在各个模块的子目录中。
编译系统需要经过初始化(setup)来完成必要的参数赋值。初始化的操作命令很简单&＃xff0c;但实际要配置的参数是非常多的&＃xff0c;Android支持不同平台上不同产品&＃xff0c;甚至是不同模块的编译&＃xff0c; 也支持编译SDK以及PC上一些常用的工具&＃xff0c;编译系统通过配置信息的指导&＃xff0c;来完成具体的编译任务。
每一次的编译任务&＃xff0c;就是给make一个Makefile文件&＃xff0c;所以&＃xff0c;每次编译任务&＃xff0c;编译系统就会经过汇集众多零散Makefile片段的过程。编译整个工程和编译一个模块&＃xff0c;最终 汇集成的Makefile是不一样的&＃xff0c;这样就能做到灵活对各个模块进行编译。
Android将编译产物都放到了out/目录下&＃xff0c;out/目录下又有host/和target/两个子目录&＃xff0c;分别表示PC上和手机上的编译产物。
接下来&＃xff0c;我们就来进一步分析编译系统的设计细节。
要使Android编译系统运转起来&＃xff0c;首先需要经过初始化&＃xff0c;其实就是完成所有参数的配置。Android编译系统的配置&＃xff0c;可以分为四个层级&＃xff0c;从下到上依次是&＃xff1a;结构级(Architecture)&＃xff0c;芯片级(Board)&＃xff0c;产品级(Product),模块级(Module)
芯片级(Architecture)&＃xff1a;涵盖CPU体系结构和指令集的配置&＃xff0c;譬如arm, x86, mips
平台级(Board)&＃xff1a;这个层级的配置通常定义在BoardConfig.mk&＃xff0c;包括内核、驱动、CPU等与硬件紧密相关的
产品级(Product): 这个层级的配置通常定义在AndroidProducts.mk&＃xff0c;包括产品名称、需要包含哪些模块和文件等
模块级(Module)&＃xff1a; 这个层级的配置都是由Android.mk定义的&＃xff0c;模块具体的一些配置&＃xff0c;包括模块名称、模块类型、对其他模块的依赖等。 要知道Android一共有多少个模块&＃xff0c;可以在AOSP的源码根目录下执行以下命令&＃xff1a;
$ find . -name Android.mk | wc -l # 笔者在Android 5.0.1下执行这个命令&＃xff0c;得到的结果是3868&＃xff0c;汗&＃xff01;
这几个层级的配置并非独立的&＃xff0c;而是在不同参数配置下相互影响的。Android提供两种方式来进行参数配置&＃xff1a;运行envsetup.sh或配置buildspec.mk
运行envsetup.sh
Android提供了一个环境初始化的脚本build/envsetup.sh&＃xff0c; 通过source命令&＃xff0c;便可以将该脚本添加到shell环境中。接着&＃xff0c;便发现多了一个lunch命令&＃xff0c;我们就是通过这个命令来配置Android初始化的参数。 除了lunch&＃xff0c;还会有很多其他命令&＃xff0c;譬如: m, mm, mmm&＃xff0c;我们会在编译系统(2)-初始化过程这篇文章中来详细介绍envsetup.sh的工作过程。
$ source build/envsetup.sh # 将envsetup.sh添加到shell执行环境中
$ lunch # 通过lunch来交互式的完成参数配置
配置buildspec.mk
该文件需要置于Android源码的根目录&＃xff0c;Android提供一个配置模板build/buildspec.mk.default&＃xff0c; 只需要将拷贝到根目录&＃xff0c;重命名后&＃xff0c;根据需要修改文件内容便可完成参数的配置。
注&＃xff1a;支持这种文件配置的方式来完成初始化&＃xff0c;是考虑到有些固定的编译场景&＃xff0c;不需要每次都重复运行envsetup.sh脚本来配置相同的参数。
无论是采用哪种方式&＃xff0c;都会涉及到以下几个重要的参数&＃xff1a;
TARGET_PRODUCT&＃xff1a;目标产品。这个参数的取值来自于一个具体产品的定义&＃xff0c;通常位于device/[manufacture]/[product]下的AndroidProducts.mk文件中&＃xff0c; 通过PRODUCT_MAKEFILES这个属性来汇集所有产品级别的配置&＃xff0c;包括产品名称PRODUCT_NAME&＃xff0c;产品品牌PRODUCT_BRAND等。产品名称PRODUCT_NAME实际上就对应到了TARGET_PRODUCT。
Android 5.0.1提供了一些默认的目标产品&＃xff1a;aosp_arm、aosp_arm64、aosp_mips、aosp_mips64、aosp_x86、aosp_x86_64&＃xff0c;分别表示arm, mips, x86上32位和64位的产品类型。 到Android实际支持的机型&＃xff0c;就有aosp_hammerhead, aosp_manta,分别表示LGE Nexus 5和SAMSUNG 4S。
TARGET_BUILD_VARIANT&＃xff1a;目标产品的版本。每一个模块都可以通过LOCAL_MODULE_TAGS这个参数来标记自己&＃xff0c;可选的标记值有user, debug, eng, tests, optional, 或samples。 设定目标产品的类型&＃xff0c;就能筛选出指定标记的模块&＃xff0c;只将符合要求的模块编译打包到最终的产品中去。
TARGET_BUILD_VARIANT有以下取值&＃xff0c;除了筛选模块&＃xff0c;还有一些调试级别的差异&＃xff1a;
TARGET_BUILD_TYPE: 目标产品的类型。只有release和debug两种取值&＃xff0c;默认的取值为release。Android源码中包含一些调试专用的代码&＃xff0c;当取值为debug时&＃xff0c;这些调试代码会编译到最终的产品中去。
TARGET_TOOLS_PREFIX: 编译工具链的路径前缀。默认情况下&＃xff0c;Android使用prebuilts目录下的工具&＃xff0c;但通过这个值也可自行定制为其他目录。
当TARGET_PRODUCT设定后&＃xff0c;编译系统就可以基于它获取其他参数了。这个产品是哪个体系结构&＃xff0c;哪个芯片&＃xff0c;内核的命令参数是什么&＃xff1f; 这些硬件相关的参数都是通过BoardConfig.mk来配置的&＃xff0c;编译系统会搜寻device和vendor目录下的$(TARGET_DEVICE)/BoardConfig.mk&＃xff0c;这样就能找到对应产品的的芯片级(Board)配置了。
BoardConfig.mk文件中参数主要有以下几个类别&＃xff1a;
CPU体系结构: TARGET_CPU_ABI&＃xff0c; TARGET_CPU_VARIANT, TARGET_ARCH, TARGET_ARCH_VARIANT等。其中一些参数的取值不同&＃xff0c;会连带引发其他参数的不同。
内核参数&＃xff1a; BOARD_KERNEL_BASE&＃xff0c; BOARD_KERNEL_PAGESIZE&＃xff0c; BOARD_KERNEL_CMDLINE这些参数最终会被打包到boot分区的镜像文件中(boot.img)&＃xff0c;作为内核的启动参数。
分区镜像: TARGET_USERIMAGES_USE_EXT4, BOARD_BOOTIMAGE_PARTITION_SIZE, BOARD_SYSTEMIMAGE_PARTITION_SIZE等与分区格式、分区大小相关的参数。
驱动: BOARD_HAVE_BLUETOOTH&＃xff0c; BOARD_WLAN_DEVICE等与蓝牙、wifi硬件配置相关的参数
不同的产品(Product)配置会对应到不同的平台(Board)配置&＃xff0c;而平台(Board)的配置也会影响到芯片(Architecture)的配置。BoardConfig.mk中定义的TARGET_ARCH和TARGET_ARCH_VARIANT两个参数决定了TARGET_ARCH_SPECIFIC_MAKEFILE这个芯片级(Architecture)的配置文件&＃xff0c;它的值等于build/core/combo/arch/$(TARGET_ARCH)/$(TARGET_ARCH_VARIANT).mk。
Android默认定义了arm, arm64, mips, mips64, x86, x86_64这几组与CPU芯片相关的编译参数。
Android编译系统的设计理念是将模块级别的配置独立出来&＃xff0c;每个模块的Android.mk都是独立的。在编译单个模块时&＃xff0c;会将模块的Android.mk添加到main.mk中&＃xff0c;形成一个Makefile。 当然&＃xff0c;模块的Android.mk必须遵循编译系统定义的规则&＃xff0c;具体的配置细节可以参见编译系统(4)-定制。这里只说明编译系统提供给模块编译的接口&＃xff1a;
| 接口变量 | 接口定义 | 作用 |
| BUILD_EXECUTABLE | executable.mk | 编译二进制可执行文件&＃xff0c;如adbd |
| BUILD_HOST_EXECUTABLE | host_executable.mk | 编译PC上的二进制可执行文件&＃xff0c;如aapt |
| BUILD_JAVA_LIBRARY | java_library.mk | 编译动态Java库文件&＃xff0c;如framework.jar |
| BUILD_HOST_JAVA_LIBRARY | host_java_library.mk | 编译PC上的Java库文件&＃xff0c;如signapk.jar |
| BUILD_SHARED_LIBRARY | shared_library.mk | 编译动态的库文件&＃xff0c;如libfilterfw.so |
| BUILD_STATIC_LIBRARY | static_library.mk | 编译静态的库文件&＃xff0c;如libip6tc.so |
| BUILD_PACKAGE | package.mk | 编译APK&＃xff0c;如SystemUI.apk |
所有接口定义的源文件&＃xff0c;都在build/core目录下&＃xff0c;在Android.mk中&＃xff0c;只需要引用这些变量&＃xff0c;就能触发一个模块的编译&＃xff0c;不同的模块使用不用的编译方式。 在将一个Android.mk文件include到main.mk中的时候&＃xff0c;也会依次将上述变量定义的.mk文件include进来&＃xff0c;从而生成最终的Makefile配置。
编译系统的运行过程可以分为两部分&＃xff1a;
合成最终的Makefile&＃xff1a;零散的Makefile片段&＃xff0c;会按照引用关系汇集到main.mk中&＃xff0c;作为最终编译的Makefile
根据依赖关系逐步构建出最终产物&＃xff1a;Makefile的编译规则最终成型为一个DAG&＃xff0c;make会按照“后根顺序(post-order)”来遍历DAG&＃xff0c;被依赖的目标总是先被执行
通过Makefile的include语法&＃xff0c;就能将其他Makefile片段包含到当前Makefile文件中来&＃xff0c;当我们在Android目录下执行make命令时&＃xff0c;实际上输入文件是根目录下的Makefile&＃xff0c;所有的片段最终都汇集到该文件中。
大体的汇集过程如下图所示&＃xff1a;
最终Makefile文件中仅仅引入了main.mk, main.mk位于build/core目录&＃xff0c;望文生意&＃xff0c;这就表示已经进入Android编译系统最为核心的部分了&＃xff0c;main.mk会做编译环境检查&＃xff0c;定义最重要的编译目标(droid)&＃xff0c;依次引入其他功能片段:
help.mk&＃xff0c;最优先引入的片段&＃xff0c;文件内容很简单&＃xff0c;就是定义了一个名为help的目标&＃xff0c;通过输入make help命令&＃xff0c;就可以看到该目标的输出结果是一些最主要的make目标的帮助信息。
config.mk&＃xff0c;文件内容很庞大&＃xff0c;目的就是为了配置编译环境。该文件定义了用于其他模块编译的常量(BUILD_JAVA_LIBRARY, CLEAR_VARS等)&＃xff0c;也定义了编译时所依赖工具的本地路径(aapt, minigzip等)&＃xff0c;同时也会引入与基于机型配置相关的其他片段(BoardConfig.mk, AndroidProducts.mk等)。
cleanbuild.mk&＃xff0c;定义了installclean这个编译目标&＃xff0c;不同于clean&＃xff0c;执行make installclean的时候&＃xff0c;并不会完整的删除out/目录&＃xff0c;而是仅仅删除与当前TARGET_PRODUCT, TARGET_BUILD_VARIANT, PRODUCT_LOCALES这属性关联到的编译产出。通俗一点来说&＃xff0c;就是删除out/target/product/目录下本次机型编译的产物&＃xff0c;out/host目录下的文件是保留下来的。
definitions.mk&＃xff0c;定义了大量的函数&＃xff0c;这些函数都是编译系统的其他文件将用到的。譬如&＃xff1a;my-dir&＃xff0c; all-subdir-makefiles&＃xff0c; find-subdir-files等&＃xff0c;通过Makefile的$(call func_name)就能调用这些函数。
dex_preopt.mk&＃xff0c;为了提升代码的运行效率&＃xff0c;Android会对可执行文件做优化&＃xff0c;即将dex格式的文件转换为odex格式的文件。在ART虚拟机下&＃xff0c;仍然采用dex(Dalvik Executable)和odex(Optimized Dalvik Executable)这个文件的命名方式&＃xff0c;但实际上ART与Dalvik的文件格式是不同的。
Android.mk&＃xff0c;Android有全编译和模块编译之分&＃xff1a;
Android.mk的编写模板基本都是一致的,它会引入很多编译系统已经初始化好的变量&＃xff0c;譬如CLEAR_VARS&＃xff0c; BUILD_JAVA_LIBRARY, 其实就是引入变量所对应的.mk文件&＃xff0c;所以Android.mk的生成过程&＃xff0c;也是一个Makefile片段的汇集过程。
post_clean.mk&＃xff0c;在引入待编译模块后&＃xff0c;就可以定义模块的清除规则了。该片段定义了基于上一次编译产出的清除规则&＃xff0c;譬如&＃xff0c;某个模块的AIDL文件或者资源发生了变化&＃xff0c;那再次编译这个模块时&＃xff0c;就需要清除上一次的编译产物。
legacy_prebuilts.mk&＃xff0c;定义了GRANDFATHERED_ALL_PREBUILT变量&＃xff0c;表示不需要经过编译的预装文件&＃xff0c;譬如gps.conf(GPS配置文件), radio.img(射频分区镜像文件)&＃xff0c;这些文件都是预编译好的&＃xff0c;只需要拷贝到编译产出即可。Android定义了一个默认的PREBUILT列表&＃xff0c;而且不希望第三方改动这个列表。当第三方有预编译文件&＃xff0c;但又不在PREBUILT列表中时&＃xff0c;就需要通过PRODUCT_COPY_FILES这个变量来指定了。
Makefile&＃xff0c;不同于AOSP根目录下的Makefile&＃xff0c;这个Makefile位于build/core目录下&＃xff0c;Android官方对这个文件的解释是”定义一些杂乱的编译规则(miscellaneous rules)”&＃xff0c;实际上&＃xff0c;这个文件相当重要&＃xff0c;诸如system.img, recovery.img, userdata.img, cache.img的目标定义都在这个文件中&＃xff0c;更笼统点说&＃xff0c;out/target/product/PRODUCT_NAME/目录下大部分的编译产出都是由该文件定义的。
最终Makefile所定义的依赖关系可以用一个有向无环图(Directed Acyclic Graph, DAG)来表示&＃xff0c;如果解析Makefile规则&＃xff0c;发现存在一个依赖环&＃xff0c;那就不是合法的Makefile规则。
可以把编译系统构建的依赖关系分成系统级和模块级别两个层面&＃xff1a;
系统级的依赖关系&＃xff0c;是指最终编译出Android系统所涉及到的目标之间的依赖。譬如编译出system.img有哪些依赖目标需要先编译完成。这一层的依赖是由编译系统定义的。
模块级的依赖关系&＃xff0c;是指各个模块之间的依赖。譬如模块A依赖模块B&＃xff0c;那么就需要将这个依赖关系告诉编译系统&＃xff0c;只有当模块B编译完成了&＃xff0c;才能开始编译模块A。这一层的依赖是由各个模块单独定义的。
3.2.2.1 系统级的依赖关系
最终生成的DAG是极其庞大的&＃xff0c;为了说明问题&＃xff0c;我们仅列出了一些关键的编译目标之间的依赖关系图&＃xff1a;
droid&＃xff0c;是最顶层的编译目标&＃xff0c;执行make命令时&＃xff0c;就会默认编译这个目标&＃xff0c;但这个目标并没有什么实质内容&＃xff0c;仅仅作为所依赖目标的组合。其中dist_files是编译产物emma_meta.zip&＃xff0c;主要用作测试覆盖率; apps_only这个编译目标是由TARGET_BUILD_APPS的值决定的&＃xff0c;当只编译指定的app时&＃xff0c;就会编译这个目标&＃xff0c;否则就编译droidcore这个目标。
droidcore&＃xff0c;Android全编译的顶层目标&＃xff0c;也仅仅作为所依赖目标的组合。boot.img, recovery.img, userdata.img, cache.img, system.img这些最终刷入设备的镜像都是被依赖的目标。
files&＃xff0c;该目标囊括所有预编译的模块prebuilt&＃xff0c;需要编译安装的模块modules_to_install&＃xff0c;这些模块的编译产物输出到最终需要打包的分区镜像文件中。
system.img&＃xff0c;在Makefile中&＃xff0c;真正的编译目标是systemiamge&＃xff0c;它依赖于INSTALLED_SYSTEMIMAGE这个变量&＃xff0c;其实就是编译完成后out/目录下的system.img&＃xff0c; 要编译system.img&＃xff0c;当然依赖于很多模块的编译产出(由ALL_DEFAULT_INSTALLED_MODULES变量描述的)&＃xff0c;这里就构成了两个目标依赖于同一个目标的依赖关系&＃xff0c;但仍然没有构成环。
userdata.img, cache.img, recovery.img&＃xff0c;这些都是分区镜像文件&＃xff0c;最终刷入设备上对应的分区&＃xff0c;它们都是被droidcore依赖的目标&＃xff0c;当然&＃xff0c;这些目标的生成也依赖于很多其他的目标。
installed-files.txt, 一个文本文件&＃xff0c;最终生成在out/目录下&＃xff0c;文件内容列出了所有安装的模块。
这里并没有把更多的依赖细节体现出来&＃xff0c;只是展开了几个很顶层的目标&＃xff0c;实际上&＃xff0c;各个目标之间的依赖关系是错综复杂的。
3.2.2.2 模块级的依赖关系
每一个模块的Android.mk文件中&＃xff0c;都可以通过LOCAL_REQUIRED_MODULES的值&＃xff0c;来设置所依赖的其他模块&＃xff0c;但这只是一个依赖关系的定义&＃xff0c;对LOCAL_REQUIRED_MODULES的处理还是编译系统完成的。
在Android.mk中&＃xff0c;都会调用编译系统提供的模板&＃xff0c;来编译一个特定的模块&＃xff0c;这是通过引用Makefile变量来实现的&＃xff0c;譬如&＃xff1a;$(BUILD_HOST_EXECUTABLE)表示编译PC机上的可执行程序&＃xff0c;$(BUILD_PACKAGE)表示编译一个APK&＃xff0c; $(BUILD_JAVA_LIBRARY)表示编译一个Java库文件。
每一个$(BUILD_XX)的变量&＃xff0c;都会对应到一个.mk文件&＃xff0c;而这些.mk文件也会引用其他.mk文件&＃xff0c;最终都会落到引用base_rules.mk中:
在base_rules.mk中&＃xff0c;待编译的模块会把自己添加到ALL_MODULES这个变量中&＃xff0c;如此一来&＃xff0c;当所有的Android.mk引入完成后&＃xff0c;ALL_MODULES就记录了所有待编译的模块。 所有被依赖的模块会保存在ALL_MODULES.$(m).REQUIRED这个变量中&＃xff0c;$(m)就是当前被引入的模块&＃xff0c;在编译$(m)这个模块的时候&＃xff0c;就会顺着ALL_MODULES.$(m).REQUIRED变量找到被依赖的模块&＃xff0c;从而构建出依赖关系图。
我们最关心的当然是一次编译能够有什么产出&＃xff0c;所有的编译产物都在out/目录下&＃xff0c;有两个子目录:host/表示针对PC上的产物&＃xff0c;target/表示针对移动设备上的产物。所有编译产物的生成过程可以大致分为三步&＃xff1a;
各个模块编译出中间产物。这些中间产物都位于host/和target/下面的obj/子目录中&＃xff0c;对于C代码而言&＃xff0c;中间产物通常就是.o文件;对于Java代码而言&＃xff0c;中间产物通常就是.jar文件。
以target/下面的obj/为例&＃xff0c;有以下类别的中间产物&＃xff1a;
对于host下面的obj/&＃xff0c;也有类似的目录结构。
链接各个中间产物&＃xff0c;生成可执行的文件。对于EXECUTABLES&＃xff0c;会在模块的临时目录生成一个二进制程序;对于SHARED_LIBRARIES&＃xff0c;会在模块的临时目录生成一个LINKED的子目录&＃xff0c;存放这最终编译完成的so库文件。
打包二进制文件&＃xff0c;生成镜像文件。譬如&＃xff0c;将各种apk、jar和so文件拷贝到system/目录&＃xff0c;打包生成system.img镜像。
TODO
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有